The offload probe has to report when the link is what ends it - #1749

…1746)

GET_DATA_RANGE answers twice - a short PENDING(2) acknowledgement, then the payload
with SUCCESS(1) - and the #689 backlog decode ran on both. The ack carries no ring
pointers by construction, so it decoded to null and logged "offsets may have moved"
once per sync on healthy hardware, pointing every reader at an alignment bug that
was not there.

The tree already knew: Framing's own result-code table records "2=PENDING precedes
SUCCESS on GET_DATA_RANGE (hardware-confirmed, #78 fork)". The decode site simply
had no way to act on it, because a too-short frame and a misaligned one look the
same to pagesBehind.

A pure isPendingResponse(frame, cmdOff) on both platforms reads the result byte at
cmdOff+2 and gates the decode at the two call sites. The SUCCESS frame that will
not parse still logs exactly as loudly as before - that is the case #818's comment
protects, and it is untouched. The #451 raw dump stays unconditional above it.

Verified against the captured bytes rather than the description. On the PENDING
frame, index 10 is 0x22 (34, GET_DATA_RANGE), 11 is the origin sequence, 12 is 0x02
- the cmdOff+2 claim is exact. That fixture is a whole frame: declLen 12, +8, and
it is 20 bytes. The SUCCESS fixture is trimmed from its declared 84 bytes to 40,
which is deliberate rather than damaged: pagesBehind reads to index 37, so the trim
keeps precisely what the decoder needs, and decoding it by hand gives w=48833,
u=48820, t=131072 -> 13, matching the log excerpt in the PR.

The two predicates are exact twins, including the detail that Kotlin masks the
signed Byte where Swift's UInt8 does not need it. Five new cases per platform,
one-to-one.

Merged onto a main that had moved a long way under it - WhoopBleClient.kt was
rewritten substantially by #1744, #1748 and #1749 after this branch was cut - so it
was merged locally and run rather than trusted: 4,926 tests, 0 failures,
DataRangeScanTest 17/17, doc lint and i18n clean, all fifteen CI checks green.

One thing left on the table for later, since the fixture already supports it:
nothing asserts pagesBehind == 13 on that SUCCESS frame. The pair currently pins
only that the two are distinguishable; asserting the value would pin that the pair
behaves exactly as the log shows, for free, on both platforms.

The PR body was edited before merge to remove a closing verb adjacent to an issue
number. It was a denial - the contributor was explicitly saying the issue should
stay open - but GitHub matches those keywords literally and does not read
negations, so it would have been actioned on merge. Harmless this time only
because that issue was already closed.

Thanks @Zebsi235 - real captured frames rather than synthetic ones, the failing
stub run to prove the tests actually catch the regression, and the Swift gap stated
up front rather than left to be found.

)

Found in the 13:17 capture, and it was my own scheduling rather than the strap.

DIS reads and CCCD writes share ONE serialized GATT queue. The probe was posted on a
fixed 6s delay, chosen on the reasoning that the DIS chain - posted at 3s - would be
done by then. On one link it was still running at 7s:

  07:57:06  writeDescriptor busy for fd4b0003 ... retry 1/8
  07:57:06  ... 8 busy retries across the four chars, shared budget exhausted
  07:57:06  writeDescriptor rejected for fd4b0003/4/5/7 (gave up after 8 retries)
  07:57:06  Unbonded offload probe: none of the 4 ... completed their subscribe, and
            none was refused either ... proves nothing either way
  07:57:07  DIS: modelNumber=MG            <- the chain, still going

Not one descriptor write reached the air. Reasoning about a delay lost to measuring
one. The probe now waits on the actual signal, checked once a second and bounded at
eight checks, then goes anyway and says which happened.

The same log also handed over a control case that #1749 asserted without one. Every
link whose CCCD writes reached the air died at 10.8s - 4.8s after the probe, by
localTerminate, the CLIENT_HELLO's own signature. The ONE link where all four writes
were abandoned locally lived 31.3s and died of an ordinary connectionTimeout. The
teardown tracks the write reaching the strap, not the probe running.

Three review passes, and all three found the same shape of defect: a flag claiming
something that had not happened.

  1. the contention itself
  2. disChainInFlight was set BEFORE readDisIdentity, which has five early returns
     above the read it issues plus an unavailable-characteristic branch - so on any of
     those the probe stood aside for a chain that never started. readDisIdentity now
     reports whether it ISSUED a read, and the flag is set from that answer rather
     than from the intention to ask.
  3. readNextDisExtra is only reached from the SUCCESS path, so a REFUSED read ended
     the chain while the flag stayed set - and #490's whole subject is a strap that
     refuses DIS, so that was the case the probe most wanted a clear queue for.

All three were survivable because the cap bounds them, which is exactly why they
would have gone unnoticed: a wrong wait that self-corrects looks like a working wait.

The wait decision also moved into a pure helper beside the rest of this file's
judgements. It was inline in the client - argued for in a comment and asserted
nowhere - which is precisely how #1755 shipped a bound every unit test agreed with
and the real pipeline rejected.

Parity checked rather than assumed: the DisUnbondedRead pure twin pair is untouched,
four functions each side, and Swift performs its DIS read inline with no
readDisIdentity counterpart, so the Bool return has no twin to keep in step. That
structural difference predates this work. Everything else is the probe, Android-only
by design.

Staging 396 / iOS 277. 4,941 tests, zero failures. Doc lint and i18n clean. The next
capture is what confirms the probe now starts on a clear queue.

…ned (#1635)

The give-up line said the strap "serves those characteristics unbonded
but does not act on commands written to them". That holds only for links
that subscribed and then stayed quiet. Since #1749 a link LOST mid-probe
charges the same budget, and those links confirm no subscribes at all —
so on the 31 Aug capture, where every charge was a lost link, retiring
the probe would have recorded the exact opposite of what that strap
demonstrated.

It is the wrong line to overclaim on. The retirement line is where a
future reader goes to find out whether the offload is possible at all,
and reading the stronger evidence off the weaker one is the mistake this
file was built to avoid — it is what the false bond of 28 Aug was.

The line now names both ways the budget can be spent and asserts neither,
since the budget does not distinguish them. Nothing is lost: the per-link
lines already record which happened each time, with the confirmed
subscribe count.

The test that pinned the old wording pinned a false claim. Repinned to
the same shape: both possibilities named, neither asserted.